Configuration management of distributed virtual switch

ABSTRACT

A method, non-transitory storage medium, and apparatus are presented for configuration management of a distributed virtual switch including components distributed on different entities in a computing system is provided. In an exemplary embodiment, a snapshot of a configuration of the distributed virtual switch is received from a management plane configured to manage the distributed virtual switch. The snapshot may include settings for the configuration at a time of taking the snapshot. A persistent storage location independent from the management plane is designated for storing the received snapshot of the configuration. After the snapshot is taken, the configuration may be retrieved from the persistent storage location and the settings of the configuration may be applied to the distributed virtual switch, a new distributed virtual switch, or an existing distributed virtual switch.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. patent application Ser. No.14/697,586 filed Apr. 27,2015, for “Configuration Management ofDistributed Virtual Switch” which is a continuation of U.S. patentapplication Ser. No. 13/472,810, for “Configuration Management ofDistributed Virtual Switch”, filed May 16, 2012, now U.S. Pat. No.9,019,977, the contents of which is incorporated herein by reference intheir entirety.

BACKGROUND

A distributed virtual switch (DVS) is a software abstraction of anaggregate switch that may include multiple virtual switches withincomputer servers (e.g., hosts). The distributed virtual switch ismanaged in a centralized management plane through a managementapplication, such as a data center management application. Themanagement application exposes an interface to manage the configurationof the distributed virtual switch. Also, the management plane maintainsthe latest configuration of the distributed virtual switch in themanagement plane's memory or back-end database.

The latest configuration is embedded in the management plane. If theback-end database or memory is lost or corrupted and the managementplane is restarted, there is no way to restore the configuration for thedistributed virtual switch. Rather, the distributed virtual switch willhave to be re-created from scratch. Additionally, only the latestversion of the configuration is stored in the management plane. Thus, ifmisconfiguration with the distributed virtual switch or port groupoccur, an administrator cannot revert to any previous configuration ordetermine any changes across multiple configuration changes that werepreviously made.

SUMMARY

A method, non-transitory storage medium, and apparatus are presented forconfiguration management of a distributed virtual switch includingcomponents distributed on different entities in a computer system isprovided. In an exemplary embodiment, a snapshot of a configuration ofthe distributed virtual switch is received from a management plane wherethe distributed virtual switch resides. The snapshot may includesettings for the configuration at a time of taking the snapshot. Apersistent storage location independent from the management plane isdesignated for storing the received snapshot of the configuration. Afterthe snapshot is taken, the configuration may be retrieved from thepersistent storage location and the settings of the configuration may beapplied to the distributed virtual switch, a new distributed virtualswitch, or an existing distributed virtual switch.

The following detailed description and accompanying drawings provide amore detailed understanding of the nature and advantages of particularembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a system for managing a configuration of a distributedvirtual switch (DVS) according to one embodiment.

FIG. 2 depicts a more detailed example of the system according to oneembodiment.

FIG. 3 depicts an example for exporting a configuration according to oneembodiment.

FIG. 4 depicts a flowchart for exporting and importing a configurationassociated with a distributed virtual switch according to oneembodiment.

FIG. 5 depicts an example of using a configuration to re-create anoriginal distributed virtual switch according to one embodiment.

FIG. 6 depicts an example for using a stored configuration as a templatefor a new distributed virtual switch according to one embodiment.

FIG. 7 depicts an example for applying a stored configuration to anexisting distributed virtual switch according to one embodiment.

FIG. 8 depicts a more detailed example of a configuration manageraccording to one embodiment.

FIG. 9 depicts a simplified flowchart of a method for applying aconfiguration of a distributed virtual switch according to oneembodiment.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousexamples and specific details are set forth in order to provide athorough understanding of particular embodiments. Particular embodimentsas defined by the claims may include some or all of the features inthese examples alone or in combination with other features describedbelow, and may further include modifications and equivalents of thefeatures and concepts described herein.

FIG. 1 depicts a system 100 for managing a configuration of adistributed virtual switch (DVS) 102 according to one embodiment. Amanagement plane server 104 operates in the management plane toconfigure and manage distributed virtual switch 102. Management planeserver 104 exposes interfaces (e.g., command line interfaces (CLI) anduser interfaces) that are used to change the configuration ofdistributed virtual switch 102 and that of distributed portgroup throughthe management plane.

A client 106 includes a configuration manager 124 that communicates withmanagement plane server 104 to have a snapshot of a configuration ofdistributed virtual switch 102 exported from the management plane. Itwill be understood that multiple clients 106 may be used. For example, afirst client 106 may export the snapshot of the configuration and then asecond client 106 may perform actions described below with respect toapplying the configuration. Clients 106 may include a user interface,application programming interface (API), or a script. The snapshot maycapture the current configuration settings for distributed virtualswitch 102. Configuration manager 124 can then determine where to storethe configuration. Because the configuration has been exported from themanagement plane, configuration manager 124 can store the configurationin different areas outside of the management plane represented broadlyby storage 108 in FIG. 1. Additionally, multiple snapshots (versions) ofthe configuration of distributed virtual switch 102 may be exported andstored.

The configuration is exported from the management plane and stored as anindependent entity from the current configuration of distributed virtualswitch 102 that is stored in the management plane. By exporting theconfiguration as an independent entity from the management plane,different actions with the saved configuration may be performed, such asre-creating an original distributed virtual switch 102, creating a newdistributed virtual switch 102 based on the stored configuration, and/orapplying the stored configuration on an existing distributed virtualswitch 102. Also, by exporting the configuration as an independententity from the management plane, multiple versions of the configurationmay be saved over time instead of just the latest version in themanagement plane. Thus, administrators are free to revert to priorconfigurations that are known to work, use the configurations to createnew distributed virtual switches 102, or apply the configuration toexisting distributed virtual switches 102.

Distributed virtual switch 102 may include a DVS configuration and alsoa port group configuration. The DVS configuration is the configurationat a distributed virtual switch level. For example, the DVSconfiguration includes network properties for connections used byvirtual machines 116 to send and receive data via proxy switches 112 toand from a network 122 via a network interface card (NIC) 120. Portgroup properties may be the configuration for various port groups 110. Aport group is a set of virtual ports that have the same configuration.As shown, distributed virtual switch 102 includes a first port group(DVPortgroup1) 110-1 and a second port group (DVPortgroup2) 110-2. Whenthe term “configuration” is used, it may mean the DVS configurationand/or the port group configuration. The configuration is described inmore detail below.

Distributed virtual switch 102 is a software abstraction that aggregatesproxy switches 112. Virtual switches 112 are instantiated invirtualization software 118 running on hosts 114, connecting a set ofvirtual machines 116. Virtual switches 112 are proxy switches that arecontrolled via distributed virtual switch 102. Virtual switches 112 mayreside on a variety of hardware in a distributed manner. However, theconfiguration of distributed virtual switch 102 is managed from acentralized position. For example, management plane server 104 is usedto manage the configuration of distributed virtual switch 102.

FIG. 2 depicts a more detailed example of system 100 according to oneembodiment. Distributed virtual switch 102 comprises DVswitch components250A, 250B, and 250C according to one embodiment. Distributed virtualswitch 102 is a software abstraction that binds virtual switches 112-1,112-2 in the managed collection into a single logical configurableentity in management plane server 104. FIG. 2 represents only two hosts114-1, 114-2 each having only a single VM 116-1, 116-2 and correspondingvirtual network interface cards (VNIC) emulators 251-1, 251-2, only forpurpose of illustration. It should be recognized that distributedvirtual switch 102 may span any number of hosts 114 each having anynumber of VMs 116, each, in turn, having any number of VNICs 251, any ofwhich may be limited in number by available hardware resources of theindividual hosts.

Distributed virtual switch 102, as a software abstraction, resides onthe management plane. However, components for a distributed virtualswitch reside on a variety of hardware, such as DVswitch components250A, 250B, and 250C reside in hosts 114-1, 114-2 as well as database270. DVswitch components 250A, 250B, and 250C are illustrated in FIG. 2with a dotted line box indicating portions of DVswitch 250A, 250B, and250C that make up a distributed virtual switch 102. The configuration ofthese components is managed centrally from management plane server 104.Virtual switches 112-1, 112-2 that are connected to the same physicalnetwork 122 are managed using one distributed virtual switch 102.Physical network 122, may be, e.g., a local area network.

As shown in FIG. 2, a single virtual port 262, 264 is maintained foreach VNIC 215-1, 215-2, respectively. Each VNIC emulator 251-1, 251-2interacts with NIC drivers 224-1, 224-2 in guest operating systems (GOS1 and GOS 2) to send and receive data to and from VMs 116-1, 116-2. Forexample, each VNIC emulator 251-1, 251-2 may maintain the state for oneor more VNICs 215-1, 215-2 for each VM 116-1, 116-2. Alternatively,multiple instances of VNIC emulators 251-1, 251-2 (only one shown foreach host 114) may be instantiated within virtualization software 118-1,118-2. For the purpose of illustration, FIG. 2 shows only one VNIC 251for each VM 116, and only one VM 116 for each host 114. Those skilled inthe art will recognize that discussion herein of VNICs 215-1, 215-2 isactually a discussion of a VNIC state implemented and maintained by eachVNIC emulator 251-1, 251-2. Virtual devices such as VNICS 215-1, 215-2are software abstractions that are convenient to discuss as though partof VMs 116-1, 116-2, but are actually implemented by virtualizationsoftware 118-1, 118-2 using emulators 251-1, 251-2. The state of each VM116-1, 116-2, however, includes the state of its virtual devices, whichis controlled and maintained by the underlying virtualization software118-1, 118-2.

The port group configuration is the shared configuration of DVports 272,274. A DVport is a software abstraction that encapsulates the“personality” (both configuration and runtime state) of a correspondingvirtual port. Thus, DVport 272 contains one or more data structuresrepresenting the configuration and runtime state of virtual port 262 ofa virtual switch 112-1. Likewise, DVport 274 contains one or more datastructures representing the configuration and runtime sate of virtualport 264 of virtual switch 602′. DVports are created with aconfiguration predefined by a network administrator. Virtual ports 262,264 are created and start with a blank configuration state, but onceassociated with a DVport 272, 274, assume the configuration and runtimestate of the associated DVport. The port configuration of DVports 272,274 is stored in a table or other data structure within database 270 asthe port group configuration.

The DVS configuration includes the connections needed to send/receivedata to/from network 122. The term “connection” is used herein todescribe an association of a virtual NIC with a DVport. In oneembodiment, this association is maintained as the DVS configuration inmanagement plane server 104. For example, the DVS configuration isstored in a table or other data structure within database 270. Also, theDVS configuration may be stored locally by virtualization software118-1, 118-2.

The exporting and importing of the configuration will now be describedin more detail. FIG. 3 depicts an example for exporting a configurationaccording to one embodiment. Client 106 may be located outside of themanagement plane. At certain times, client 106 may request theconfiguration of distributed virtual switch 102 may be exported toclient 106.

As shown, management plane server 104 exports a DVS configuration andport group configuration. It should be recognized that only the DVSconfiguration or the port group configuration may be exported. Client106 then can determine where to store the DVS configuration and portgroup configuration. For example, storage 108 may be memory or apersistent database independent from the management plane.

Users are allowed to export the configuration as many as time as theuser wants. A stored configuration may then be imported at a later time.For example, after exporting the configuration, client 106 may import aprevious configuration to re-create the original distributed virtualswitch 102, create a new distributed virtual switch 102, or apply theconfiguration to an existing distributed virtual switch 102. FIG. 4depicts a flowchart for exporting and importing a configurationassociated with distributed virtual switch 102 according to oneembodiment.

At 402, management plane server 104 exports a configuration of a versioni (Vi) for distributed virtual switch 102. Storage 108 may includemultiple versions of the configuration that were exported at differenttimes. A revision control system can be built on top of this as multipleversions of the configuration can be stored instead of only the latestconfiguration. The versions are exported from the management plane, suchas in a datacenter, to storage 108, which is external from themanagement plane.

At 404, distributed virtual switch 102 may be re-configured manydifferent times to go through different versions. At 406, client 106 mayimport a configuration (e.g., version Vi) from storage 108 to apply to adistributed virtual switch 102. The import operation can be executed indifferent modes. For example, an existing distributed virtual switch 102may revert to the previous version, Vi, using the configuration forimport in “apply-to-existing” mode. Additionally, a new distributedvirtual switch 102 may be created using the previous version of theconfiguration for import in “create-new” mode, or the originaldistributed virtual switch 102 may be re-created for import in“create-original” mode. FIGS. 5-7 depict these different scenarios.Other scenarios of using the configuration may also be appreciated.

FIG. 5 depicts an example of using a configuration to re-create anoriginal distributed virtual switch 102 according to one embodiment. At502, a configuration including a DVS configuration and a port groupconfiguration is exported to client 106, which stores the configurationin storage 108 at 504. At 506, when client 106 wants to re-create theoriginal distributed virtual switch (DVS A) 102, the storedconfiguration from storage 108 is sent to configuration manager 124.

At 508, configuration manager 124 re-creates the original distributedvirtual switch 102. The re-created distributed virtual switch 102includes the same DVS configuration and port group configuration. Theidentifier (DVS A) of distributed virtual switch 102 and the port groupidentifier (DVPortgroup1) are the same. Also, in this case, the originaldistributed virtual switch 102 was coupled to host 114. Thus, there-created original distributed virtual switch 102 is also coupled tothe same host 114. This is because the configuration is the same in there-created distributed virtual switch 102. The re-created distributedvirtual switch 102 may be re-created in the same management plane server(server A) or a different management plane server (e.g., a server B).The VM and host 114 may automatically communicate through the re-createddistributed virtual switch 102 without disruption.

One use case for users to re-create a distributed virtual switch 102 maybe to migrate a distributed virtual switch from a test environment to aproduction environment. An administrator may test distributed virtualswitch 102 in the testing setup. After testing, an administrator maywant to move the distributed virtual switch 102 to a production setup.In this case, the administrator exports the tested configuration fromthe management plane to storage 108. Then, the tested configuration isimported to re-create distributed virtual switch 102 in the productionsetup with the original configuration from the test setup. Theproduction setup re-creates the distributed virtual switch 102 that isused in the test setup so the connections in host 104 remain the sameand virtual machines that use the distributed virtual switch 102 are notimpacted.

FIG. 6 depicts an example for using a stored configuration as a templatefor a new distributed virtual switch. At 602, management plane server104-1 exports the DVS configuration and port group configuration ofdistributed virtual switch (DVS A) 102-1 to client 106. At 604,configuration manager 124 stores the configuration in storage 108 and at606, client 106 retrieves the configuration to create a new distributedvirtual switch 102-2.

At 608, configuration manager 124 creates a new distributed virtualswitch (DVS B) 102-2 using the configuration of distributed virtualswitch 102-1. In such a case, the configuration of distributed virtualswitch 102-1 is used as a template. The port group configuration ofdistributed virtual switch 102-1 is used to create a new port groupconfiguration (DVPortgroup2) 110-2.

A clone of the original distributed virtual switch 102-1. may be createdin the original management plane server (server A) 104-1 or anothermanagement plane server (server B) 104-2. In either case, the newdistributed virtual switch 102 would be created with new identifiers(DVS B/DVPortgroup2). Using the stored configuration as a templateallows an administrator to more easily create the new distributedvirtual switch 102.

FIG. 7 depicts an example for applying a stored configuration to anexisting distributed virtual switch 102 according to one embodiment. At702, server (server A) 104-1 exports a configuration of distributedvirtual switch 102-1 to client 106. At 704, client 106 stores theconfiguration in storage 108 and at 706, client 106 retrieves theconfiguration from storage 108 when the configuration is to be appliedto an existing distributed virtual switch 102.

In one example, the retrieved configuration may be applied to theoriginal distributed virtual switch 102-1. For example, at 710,configuration manager 124 applies the configuration on the originaldistributed virtual switch (DVS A) 102-1 on server 104-1 (server A).This would apply a previous version of the DVS configuration and portgroup configuration to distributed virtual switch 102-1.

In another example, at 714, configuration manager 124 may apply theconfiguration to another server (server B) 104-2. For example, theconfiguration of original distributed virtual switch (DVS A) 102-1 maybe applied on server B. If existing port group 110-1 is used, then thestored port group configuration (DVPortgroup1) is used to apply theexisting port group 110-1 to DVS A. Also, at 716, configuration manager124 applies the port group configuration to a new port group(DVPortgroup2) 110-2 in distributed virtual switch (DVS B) 102-2.

FIG. 8 depicts a more detailed example of configuration manager 124according to one embodiment. An export manager 802 manages the storingof configurations for distributed virtual switches 102. In oneembodiment, servers 104 may be requested by a client 106 to export theconfigurations for distributed virtual switches 102 to storage 108. Theexporting of the configurations may go through client 106.

An import manager 802 receives the retrieved configuration and is thenconfigured to apply the configuration to a server 104. For example,different managers 810 are provided to perform different actions inapplying the configuration. For example, an original switch exportmanager 810-1 re-creates the original distributed virtual switch 102. Anexisting switch export manager 810-2 applies the configuration to anexisting distributed virtual switch 102. A new switch export manager810-3 uses the configuration to create a new distributed virtual switch102.

FIG. 9 depicts a simplified flowchart 900 of a method for applying aconfiguration of a distributed virtual switch 102 according to oneembodiment. At 902, client 106 sends a request to server 104 to retrievethe configuration for a distributed virtual switch 102. At 904,configuration manager 124 receives the request to retrieve theconfiguration of a distributed virtual switch 102.

At 906, client 106 stores the configuration in storage 108. Anidentifier for a configuration of a certain distributed virtual switch102 that was saved at a certain time (e.g., a version) may be storedwith the configuration. At 908, client 106 retrieves the specifiedconfiguration from storage 108.

At 940, configuration manager 124 receives a command for an action toperform with the configuration. For example, an administrator may chooseto apply the configuration in different ways as described above. At 912,configuration manager 124 applies the configuration based on the inputreceived from the administrator at 910.

Particular embodiments provide many advantages. For example, storing theconfiguration of distributed virtual switch 102 as a separate,independent entity in storage 108 enables administrators to publish andshare the configuration with other administrators or systems. Theseconfigurations may be used to enforce certain policies for switchmanagement across distributed virtual switches 102. Additionally,administrators may manipulate the configurations separately and thenapply the manipulation to create new distributed virtual switches 102 ormanipulate existing distributed virtual switches 102.

Further, because multiple versions of the configuration for distributedvirtual switches 102 are saved, an administrator may revert to aprevious version that was known to be working. This may provide highavailability allowing an administrator to replace a non-workingdistributed virtual switch 102 with a configuration that is known to beworking. The administrators are also freed up from the availabilityissues of the management plane because the configuration of adistributed virtual switch 102 may always be re-created using abacked-up version. The administrator knows that a working version isstored in storage 108 and thus can always revert when a distributedvirtual switch 102 is not working. Additionally, by backing up differentversions, a revision control system is provided. An administrator mayback up a configuration upon each change to the configuration, and thenrevert to any previously backed up configuration if any changes areundesirable.

The various embodiments described herein may employ variouscomputer-implemented operations involving data stored in computersystems. For example, these operations may require physical manipulationof physical quantities—usually, though not necessarily, these quantitiesmay take the form of electrical or magnetic signals, where they orrepresentations of them are capable of being stored, transferred,combined, compared, or otherwise manipulated. Further, suchmanipulations are often referred to in terms, such as producing,identifying, determining, or comparing. Any operations described hereinthat form part of one or more embodiments may be useful machineoperations. In addition, one or more embodiments also relate to a deviceor an apparatus for performing these operations. The apparatus may bespecially constructed for specific required purposes, or it may be ageneral purpose computer selectively activated or configured by acomputer program stored in the computer. In particular, various generalpurpose machines may be used with computer programs written inaccordance with the teachings herein, or it may be more convenient toconstruct a more specialized apparatus to perform the requiredoperations.

The various embodiments described herein may be practiced with othercomputer system configurations including hand-held devices,microprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like.

One or more embodiments may be implemented as one or more computerprograms or as one or more computer program modules embodied in one ormore computer readable storage media. The term computer readable storagemedium refers to any data storage device that can store data which canthereafter be input to a computer system—computer readable media may bebased on any existing or subsequently developed technology for embodyingcomputer programs in a manner that enables them to be read by acomputer. Examples of a non-transitory computer readable medium includea hard drive, network attached storage (NAS), read-only memory,random-access memory (e.g., a flash memory device), a CD (CompactDiscs)—CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), amagnetic tape, and other optical and non-optical data storage devices.The computer readable medium can also be distributed over a networkcoupled computer system so that the computer readable code is stored andexecuted in a distributed fashion.

In addition, while described virtualization methods have generallyassumed that virtual machines present interfaces consistent with aparticular hardware system, persons of ordinary skill in the art willrecognize that the methods described may be used in conjunction withvirtualizations that do not correspond directly to any particularhardware system. Virtualization systems in accordance with the variousembodiments, implemented as hosted embodiments, non-hosted embodimentsor as embodiments that tend to blur distinctions between the two, areall envisioned. Furthermore, various virtualization operations may bewholly or partially implemented in hardware.

Many variations, modifications, additions, and improvements arepossible, regardless the degree of virtualization. The virtualizationsoftware can therefore include components of a host, console, or guestoperating system that performs virtualization functions. Pluralinstances may be provided for components, operations or structuresdescribed herein as a single instance. Finally, boundaries betweenvarious components, operations and data stores are somewhat arbitrary,and particular operations are illustrated in the context of specificillustrative configurations. Other allocations of functionality areenvisioned and may fall within the scope of the invention(s). Ingeneral, structures and functionality presented as separate componentsin exemplary configurations may be implemented as a combined structureor component. Similarly, structures and functionality presented as asingle component may be implemented as separate components.

These and other variations, modifications, additions, and improvementsmay fall within the scope of the appended claims(s). As used in thedescription herein and throughout the claims that follow, “a”, “an”, and“the” includes plural references unless the context clearly dictatesotherwise. Also, as used in the description herein and throughout theclaims that follow, the meaning of “in” includes “in” and “on” unlessthe context clearly dictates otherwise.

The above description illustrates various embodiments along withexamples of how aspects of particular embodiments may be implemented.The above examples and embodiments should not be deemed to be the onlyembodiments, and are presented to illustrate the flexibility andadvantages of particular embodiments as defined by the following claims.Based on the above disclosure and the following claims, otherarrangements, embodiments, implementations and equivalents may beemployed without departing from the scope of the invention as defined bythe claims.

What is claimed is:
 1. A system comprising: a distributed virtual switchcomprising a first set of configuration settings; a management planeserver configured to manage the distributed virtual switch; and aconfiguration manager configured to receive a snapshot of thedistributed virtual switch from the management plane server, thesnapshot including a second set of configuration settings of thedistributed virtual switch based on a time the snapshot was taken; andstore a copy of the snapshot in a storage external to the managementplane server.